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Early in the development of the Space Shuttle, it became clear that NASA needed a 
method of deploying and retrieving payloads from the payload bay. The Shuttle Remote 
Manipulator System (SRMS) was developed to fill this need. The 50 foot long robotic arm is 
an anthropomorphic design consisting of three electromechanical joints, six degrees of 
freedom, and two boom segments. Its composite boom construction provided a light weight 
solution needed for space operations. Additionally, a method of capturing payloads with the 
arm was required and a unique End Effector was developed using an electromechanical 
snare mechanism. The SRMS is operated using a Displays and Controls Panel and hand 
controllers located within the aft crew compartment of the shuttle. Although the SRMS was 
originally conceived to deploy and retrieve payloads, its generic capabilities allowed it to 
perform many other functions not originally conceived of. Over the years it has been used 
for deploying and retrieving constrained and free flying payloads, maneuvering and 
supporting EVA astronauts, satellite repair, International Space Station construction, and as 
a viewing aid for on-orbit International Space Station operations. After the Columbia 
accident, a robotically compatible Orbiter Boom Sensor System (OBSS) was developed and 
used in conjunction with the SRMS to scan the Thermal Protection System (TPS) of the 
shuttle. These scans ensure there is not a breach of the TPS prior to shuttle re-entry. 
Ground operations and pre mission simulation, analysis and planning played a major role in 
the success of the SRMS program. A Systems Engineering Simulator (SES) was developed 
to provide a utility complimentary to open loop engineering simulations. This system 
provided a closed-loop real-time pilot-driven simulation giving visual feedback, display and 
control panel interaction, and integration with other vehicle systems, such as GN&C. It has 
been useful for many more applications than traditional training. Evolution of the 
simulations, guided by the Math Model Working Group, showed the utility of input from 
multiple modeling groups with a structured forum for discussion.There were many unique 
development challenges in the areas of hardware, software, certification, modeling and 
simulation. Over the years, upgrades and enhancements were implemented to increase the 
capability, performance and safety of the SRMS. The history and evolution of the SRMS 
program provided many lessons learned that can be used for future space robotic systems. 
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I. System Description and Evolution of the Shuttle Remote Manipulator System 


T HE fundamental requirement of the Shuttle Remote Manipulator System (SRMS) was to deploy and retrieve 
payloads to and from space. To accomplish this mission, the system that was developed consisted of an 
anthropomorphic manipulator arm located in the shuttle cargo bay (shown in Figure 1), cabin equipment to provide 
an interface to the main shuttle computer, and a human interface to allow an astronaut to control arm operations 
remotely. 



Figure 1. SRMS in the pre-cradle position looking aft in the shuttle payload bay 


A. Hardware Overview 

The manipulator arm consists of three joints, two arm booms, an end effector, a Thermal Protection System, and 
a closed-circuit television system. Figure 2 breaks down the primary SRMS components. The arm joints included a 
shoulder joint with two degrees of freedom (yaw and pitch), an elbow joint with one degree of freedom (pitch), and 
a wrist joint with three degrees of freedom (pitch, yaw, and roll). Each joint degree of freedom consists of a motor 
module driving a gear box to effect joint movement and appropriate local processing to interpret drive commands 
originating from the cabin electronics. 

The cabin electronics includes a displays and controls subsystem that provides the human-machine interface to 
allow a crew member to command the arm and view displays of appropriate information, including arm position and 
velocity, end effector status, temperature, and caution and warning information. Additionally, in the displays and 
controls subsystem, two hand controllers allow man-in the-loop control of the end point of the arm. The main arm 
processor is the manipulator controller interface unit (MCIU) that is also part of the cabin electronics. It handles all 
data transfer between the arm, displays and controls panel, and the main shuttle computer. The main shuttle 
computer processes commands from the operator via the displays and controls panel; receives arm data to determine 
real-time position, orientation, and velocity; and then generates rate and current limit commands that are sent to the 
arm-based electronics. The arm is thermally protected with specially designed blankets to reduce the susceptibility 
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of the hardware to the thermal extremes experienced during spaceflight and has an active thermostatically controlled 
and redundant heater system. 
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Figure 2. Primary SRMS Components (Source - Reference 1) 


The closed-circuit television system consists of three cameras. A color camera on a pan/tilt unit near the elbow 
joint was used as a situational awareness camera for the SRMS operator. A second camera in a fixed location on the 
wrist joint was primarily used to view a grapple fixture target when the arm was capturing a payload. A third camera 
called the SRMS Side-view Camera was added after the Columbia accident. This was fixed on the inboard side of 
the wrist joint and was used as a situational awareness camera when the SRMS was performing Shuttle Thermal 
Protection System inspections with the Orbiter Boom Sensor System (discussed later). 

Self-checks exist throughout all the Shuttle Robotic Arm electronics to assess arm performance and apply 
appropriate commands to stop the arm, should a failure occur. Caution and warning displays provide the operator 
with insight into the cause of the failure and remaining capability to facilitate the development of a workaround 
plan. 

B. SRMS Operating Modes 

The operating modes of the SRMS included Automatic modes, Manual Augmented modes, Single drive, Direct 
drive and a Back-up drive. Auto, Manual Augmented, and Single drive mode were supported with the main Shuttle 
computer and included servo joint rate control. Maximum joint rates were determined pre-flight and varied based on 
the payloads being handled. Direct and Back-up drive modes were hardwired, reduced capability modes that applied 
a fixed voltage to the joint drive amplifier. 

Automatic modes included pre-programmed and operator commanded auto sequences. The pre-programmed 
sequences were developed prior to flight and loaded into the main shuttle computer. The operator commanded auto 
sequence mode required the operator to input a final SRMS position and orientation before arm motion was 
initiated. Auto sequences were used primarily for shuttle and payload surveys and lengthy repositioning maneuvers. 
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Manual Augmented modes allowed the SRMS operator to manipulate the SRMS position and orientation real 
time using the Translational and Rotational hand controllers. The Point of Resolution and co-ordinate axes could be 
varied depending on the operation being performed. This mode was used for grappling, berthing and un-berthing 
payloads, track and capture of free flying payloads, and coarse positioning of the SRMS. 

Single joint drive allowed the operator to control each joint individually. This mode was used primarily to cradle 
and un-cradle the arm, and for fine positioning of the SRMS. 

Direct and Back-up drive modes were used for contingency arm motion should computer supported modes be 
lost. They allowed only single joint control. 

C. The SRMS End Effector 

The interfacing end of the Shuttle Robotic 
Arm is equipped with an electromechanical 
End Effector. Figure 3 shows a picture of the 
End Effector on the end of the SRMS wrist 
joint. The wrist camera/light assembly is also 
shown. The End Effector is the equivalent to 
a human hand and is used to grapple a 
payload fitted with a specially designed 
interface known as a grapple fixture. A 
picture of a grapple fixture is shown in 
Figure 4. 

The grapple fixture includes a grapple 
pin, a target, and three alignment cams that 
mate to cam lobes on the End Effector. The 
End Effector uses a three cable snare 
mechanism that closes around the grapple pin 
(see Figure 5). Once grappled to the pin, the 
snare mechanism is drawn inward into the 
main body of the End Effector to “rigidize” 
the payload to the SRMS. The cams ensure 
there is no End Effector/Grapple fixture 
motion once the payload is captured. 

The standard grapple fixture is called a 
Flight Releasable Grapple Fixture, since it is 
equipped with a mechanism that can be 
activated by an EVA crewman to release the 
grapple pin should the End Effector fail while 
grappled to a payload. 

The End Effector is also equipped with 
an electrical connector called a Special 
Purpose End Effector (SPEE) connector. This 
connector is fed with sixteen power and data 
lines from a cable harness routed along the 
length of the SRMS. This connector can mate 
to a specially designed grapple fixture called 
an Electrical Flight Grapple Fixture (EFGF). 

When captured, a payload equipped with an 
EFGF can be sent power and data signals 
through the SRMS cable harness. A switch 
panel within the Shuttle was configured to 
provide these signals. 

To track and capture a payload required 
the use of the grapple fixture target in 
conjunction with SRMS wrist camera. The 
camera is oriented to allow a straight on view of the target. The camera video was displayed to the crew in the aft 
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Figure 3: SRMS End Effector and Wrist Camera /Light 
(Source - Reference 1) 



Figure 4: Grapple Fixture (Source - Reference 1) 


flight deck, and helped the crew properly 
position the end effector relative to the 
grapple fixture prior to capturing a payload. 
An overlay on the CRT display was used to 
aid the crewman in determining when the 
End Effector was over the grapple pin and 
ready for capture. The SRMS was 
maneuvered to position the camera view of 
the grapple fixture target within the 
boundaries of the overlay. When satisfied 
with the relative position of the End 
Effector to the grapple fixture target, the 
crew used a switch on the Rotational Eland 
Controller to capture and secure the 
payload. The End Effector could be 
operated in either automatic or manual 
modes. In automatic mode the rigidize 
command would be initiated automatically 
after the snares were closed around the 
grapple pin. This was the standard mode of 
operation. Manual mode required the 
crewman to input the snare close and 
rigidize commands separately. 



II. SRMS History of Operations 

The SRMS first flew on STS-2, and by the end of the Shuttle program it had flown a total of ninety-one missions. 
While originally envisioned only for satellite deployment and retrieval, the utility of a robotic arm for other tasks 
quickly became clear. Over the life of the program the SRMS evolved into an indispensible tool not only for satellite 
deployment and retrieval, but was used extensively for satellite rescue and repair, as an EVA platform, International 
Space Station construction, shuttle and payload bay surveys, as well as a host of contingency operations. 

There were only three on orbit failures in the history of the SRMS program and only one of these failures 
prevented completion of the mission. This was STS-41B when the wrist yaw motor commutator failed causing loss 
of all primary modes of operation. The payload scheduled to be deployed (the SPAS satellite) had to remain in the 
payload bay. The second failure was on STS-51I when the power to the elbow joint electronics was shorted to 
ground. The crew managed to complete payload operations using back-up drive for the elbow joint and single joint 
drive for the other joints. The third failure was due to an incorrectly installed SPEE connector that prevented power 
and data transfer to the payload (EURECA satellite). The satellite was berthed and the data transfer took place via a 
payload bay connector. 

Other less significant failures were experienced, and these were all worked by the ground team and the crew to 
allow completion of the mission with no loss of functionality in the SRMS. The reliability of the SRMS in its thirty 
year history is testament to the excellent design, manufacturing and testing teams, and to the ground support 
personnel working with the rest of the shuttle team. The SRMS has proven its worth and has provided a blue print 
for future robotic arms in space. 

A. Satellite Deployment, Retrieval, and Servicing 

The list of satellites that were deployed and retrieved by the SRMS is long and impressive. The heavy lift 
capability of the Shuttle combined with the capabilty of the SRMS allowed unique satellite missions to be designed 
that were not previously possible. The retrieving capability of the SRMS made on-orbit repair and maintenance of 
satellites a reality for the first time. 

Figure 6 is a picture of the SRMS deploying the Gamma Ray Observatory (GRO) on STS-37. Other payloads of 
note deployed by the SRMS include the Earth Radiation Budget Satellite (ERBS) on STS-41G, and the Upper 
Atmosphere Research Satellite (UARS) on STS-48. 
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The majority of payloads deployed were 
also retrieved by the SRMS. The first 
successful capture of a free flying payload 
was on STS-7 when the SPAS-1 satellite, 
originally deployed earlier in the mission, was 
captured and berthed in the payload bay by 
the SRMS. Other deployments and captures 
include SPARTAN on STS-51G, the Plasma 
Diagnostics Package (PDP) on STS-51F, and 
the SPAS-2 payload on STS-39. The Long 
Duration Exposure Facility (LDEF) was 
deployed on STS-41C and retrieved on STS- 
32 (see Figure 7). The European Retrievable 
Carrier satellite (EURECA) was deployed on 
STS-46 and retrieved on STS-57. 

The SRMS also played the primary role in 
rescuing malfunctioning satellites. For 
example, during STS-41C, it was used to 
grapple and berth the spinning Solar 
Maximum Mission satellite (Solar Max). It 
had been deployed in 1980 and had been 
fitted with a grapple fixture to allow capture 
with the SRMS. The track and capture 
capability of the SRMS was put to the test 
due to the high spin rate of Solar Max. The 
SRMS was used on STS-51A during the 
retrieval of two malfunctioning comsats, 
Palapa B2 and Westar VI, which were 
subsequently refurbished on Earth and re- 
flown. One of the more notable SRMS 
accomplishments was the deployment of the 
Hubble Space Telescope (HST) on STS-31 in 
April, 1990. This was followed by four 
successful HST servicing missions (STS-61 
in 1993, STS-103 in 1999, STS-109 in 2002, 
and STS-125 in 2009) during which the 
SRMS was used to retrieve, repair and 
redeploy the space telescope. The final 
servicing mission, STS-125, is expected to 
extend the life of the HST to 2014. 



Figure 6. STS-37 - Deploying the Gamma Ray Observatory 



Figure 7: Maneuvering the Long Duration Test Facility on 


STS-32 


B. Extra Vehicular Activity (EVA) Platform 

A mobile work platform for EVA astronauts became one of the most important uses for the SRMS. The arm was 
used extensively in this capacity, both for pre-planned operations and for contingency EVA’s planned real-time that 
were needed for inspection or repair. The EVA crewmember could be mounted on a portable foot restraint attached 
directly to the SRMS, or he could be mounted to the Manipulator Foot Restraint (MFR) that was grappled by the 
End Effector, or the crewman could simply grab the EVA handhold attached to the End Effector. The arm operator 
inside the shuttle could easily position the EVA crewmember anywhere within the reach capability of the arm. The 
stable platform provided by the SRMS allowed the crewman to perform tasks much easier than if he were free 
floating. Radio communication between the EVA crewman and the arm operator enabled quick repositioning as 
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required. Tool stanchions and holders 
were developed to aid in the repair and 
maintenance activites. There are many 
examples during the life of the Shuttle 
program where the SRMS was used to 
support EVA, but none provide more 
concrete evidence of the value of a 
robotic arm as an EVA platform than 
the HST repair missions. 

The Hubble Space Telescope, 
deployed on STS-31 (1990), gave the 
world a perspective of outer space 
never before seen. The first servicing 
mission repaired a problem with the 
telescope’s main lens assembly. The 
subsequent missions replaced and 
enhanced onboard instrumentation. 
This improved the accuracy and 
extended the life of HST. Figure 8 
shows an EVA crewman on the end of 
the SRMS preparing for a Hubble 
repair task. More than any other 
payload, the Hubble servicing missions 
displayed to the world the unique 
capabilities of the SRMS. 



C. The Era of Space Station Construction 



The SRMS was the primary mechanism used for early International Space Station (ISS) construction. During the 
later stages when the ISS was so large that the SRMS could not reach many berthing locations, the SRMS was used 
in conjunction with the 
Space Station Remote 
Manipulator System 

(SSRMS) to complete the 
construction. In fact, the 
SRMS served as the proof 
of concept for the SSRMS, 
and many of the design 
features, capabilities and 
operations of the SRMS 
were used in the design and 
development of the 
SSRMS. Figure 9 shows 
the ISS P5 Truss segment 
being handed off on STS- 
105. ISS elements that 
were handled by the SRMS 
included Nodes 1,2 and 3, 
the US Laboratory Module 
the Space Station Airlock, 
nine truss segments, many 
of which contained solar 

panels for power to the station; and the Space Station Remote Manipulator System (SSRMS). These activities 
required some modifications to the SRMS itself, as well as the addition of systems to enhance alignment and 


Figure 9: Handing off the ISS P5 Truss Segment from SRMS to SSRMS 
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berthing operations. During the preliminary planning, studies evaluated the adequacy of the SRMS to handle the 
anticipated payload operations envisioned for the space station construction. These studies determined that arm 
controllability would not be satisfactory for the massive payloads the arm would need to manipulate. Redesigning 
the Servo Power Amplifiers (part of the Arm Based Electronics) in each joint provided the necessary controllability. 
Also, the addition of increased self-checks assured better control of hardware failures that could cause hazardous on- 
orbit conditions. During the process of assembling the space station, enhanced berthing cue systems were necessary 
to mate complicated interfaces that would need to transmit loads and maintain a pressurized interior. The complexity 
and close tolerance of mating parts led to the development of several berthing cue systems, such as the space vision 
system and the centerline berthing cue system, to enhance the crew’s ability to determine relative position between 
mating modules. 

D. Return to Flight After the Columbia Accident - The Orbiter Boom Sensor System 

During the launch of the Space Shuttle Columbia on STS-107 (2003), a piece of debris hit the shuttle, causing a 
rupture in the Thermal Protection System that is necessary for re-entry into Earth’s atmosphere, thereby leading to 
the Columbia accident. The ramifications of this breach in the shuttle’s Thermal Protection System changed the role 
of the SRMS substantially for all post-Columbia accident missions. Development of the robotically compatible 50-ft 
Orbiter Boom Sensor System (OBSS), carried on the starboard mai=nipulator positioning mechanisms, provided a 
shuttle inspection and repair capability that addressed the Thermal Protection System inspection requirement for 
post-Columbia Return to 
Flight missions. Figure 
10 shows the OBSS 
grappled by the SRMS. 

Modification of the 
robotic arm wiring 
provided power and data 
capabilities to support 
the inspection cameras 
and lasers at the tip of 
the inspection boom. 

Two shuttle repair 
capabilities were 

provided in support of 
the Return to Flight 
effort. The first scenario 
required the SRMS, 
grappled to the space 
station, to position the 
shuttle and the space 
station in a configuration 
that would enable a crew 
member on the Space 

Station Robotic Arm to perform a repair. This was referred to as the Orbiter Repair Maneuver (ORM). The second 
repair scenario involved the Shuttle Robotic Arm holding the boom with the astronaut at the tip. 

All of the post-Columbia-accident missions employed the SRMS and Orbiter Boom Sensor System combination 
to survey the shuttle for damage. The SRMS and OBSS were used to inspect all critical Thermal Protection System 
surfaces. After the imagery data were processed, focused inspections occasionally followed to obtain additional 
images of areas deemed questionable from the inspection. A detailed test objective on STS-121 (2006) demonstrated 
the feasibility of having a crew member on the end of the OBSS grappled by the SRMS and performing actions 
similar to those necessary for Thermal Protection System repair. Test results showed that the integrated system 
could be used as a repair platform and that the system was controllable with the correct control parameters, good 
crew training, and proper extravehicular activity procedures development. 

In support of shuttle repair capability using the Orbiter Repair Maneuver described earlier, the simulation model of 
the SRMS was updated to evaluate the handling of the space station as a “payload”. This heavy payload model 
update proved useful when it was decided to repair the Flubble Space Telescope on STS-125. This is because after 
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the Columbia accident, a method of crew rescue was mandatory for all shuttle flights. A “Launch on Need” shuttle 
was manifested for crew rescue should the shuttle on orbit sustain damage that would prevent re-entry. Given that 
the space station would not be available for crew rescue for the final Hubble servicing mission, the SRMS would be 
used to grapple the failed Shuttle. For the crew from the disabled shuttle to get to the rescue shuttle, the Shuttle 
Robotic Arm would act as a path for crewmen to transfer between the two vehicles. The updated SRMS simulation 
for heavy payloads proved its worth when developing and validating this rescue scenario. Fortunately, neither of 
these repair/rescue capabilities — Orbiter repair maneuver or Hubble rescue — ever had to be used. 


III. Unique Challenges in the Development of the SRMS 

A. Mechanical Design 

As with all space systems, a tradeoff between mass and strength/stiffness had to be considered in the mechanical 
design of the SRMS. With stiffness a primary consideration along with low mass, the material chosen for the 
booms of the SRMS was a carbon composite material. In addition to stiffness, the high strength to weight ratio of 
carbon composite makes it ideal for space applications. 

Additionally stiffness was the driver in the design of the joints. The elbow joint, having only one degree of 
freedom, could not relieve forces and moments acting in off-axis directions, so strength was also a primary driver in 
its design. The joint construction was primarily fabricated aluminum housings, with some steel and titanium for 
higher load bearing components. The gears were made from Carpenter Custom 455 steel, an exceptionally high 
strength material (reference 1). 

The joint actuation design was electro-mechanical using brushless DC motors and high ratio gear boxes. 
Identical motors were used in every joint to minimize qualification requirements. Hydraulic joints were considered 
however the potential for contamination from hydraulic fluid leakage eliminated this option. The choice to use 
relatively small motors driving the joint through a gear box, instead of larger motors in a direct drive configuration, 
was driven by the need to reduce weight. The gear ratios were adjusted based on the motor torque characteristics, 
and the requirement for high forward and backdrive efficiency, low backlash, and high drive train stiffness 
(reference 1). 

Each gearbox was designed with two stages. The first stage was a high speed design and the gear reduction ratio 
varied from joint to joint to meet the specific joint torque requirement. The second stage was identical in all joints 
and was a planetary design that maximized the number of load paths and provided high stiffness and low backlash. 

Backdrivability was a key driver in the design of the joints. High external loads can result in forces and moments 
applied to the arm that exceed its structural capability. Joints that can be backdriven will reduce the potential for 
this excessive loading. The back drivability requirement drove the need for high gearbox efficiencies. 

The efficiency and back drivability requirements led to problems in the manufacture of the gearboxes. Tight 
tolerances in manufacture are necessary to achieve the degree of backlash and friction required to meet the control 
system requirements. Gears had to be chosen based on a "select-on-manufacture" program resulting in a low yield 
rate and higher costs. 

To ensure the joints did not apply excessive loads when the joints were in forward drive mode, motor current 
limiting was implemented in the servo power amplifiers that provided the electrical power to the motors. The 
forward and backdrive current limits were matched to the gearbox effieciencies. Thus dynamic conditions were 
similar in all four quadrants of the drive system. 

The joint motor was chosen to minimize weight and eliminate maintenance. The brushless design avoided the 
wear and tear of commutator brushes. The motor chosen was a frameless design, so it was assembled in a housing 
that included the motor and commutator, plus a brake and a tachometer. The entire unit was called the motor module 
and was common to all six joints. To ensure servo stability when the motor was driving in a no load condition, a 
flywheel was added. 

Dynamic braking using the motor to decelerate the joint was also incorporated into the joint design. This 
eliminated the requirement to apply mechanical brakes each time a drive command was removed and prevented 
excessive wear on the brakes. This was required to meet the life requirements (originally 10 years but extended as 
the program evolved). 

The SRMS electronics had extensive Built-In Test Equipment (BITE) that detected potentially catastrophic 
failures and automatically applied brakes to prevent joint runaway and inadvertent contact between the arm and 
external shuttle/payload structure. To reduce the potential to exceed the structural load limits of the arm under these 
malfunction conditions, the joints had to be backdrivable with the brakes applied. Thus the brakes had to be 
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designed not only to provide a minimum holding torque, but also a maximum torque. It was found that the holding 
torque of the original brake material (an asbestos derivative) degraded with prolonged exposure to a vacuum due to 
moisture loss. To solve this problem, the motor modules were refitted with ceramic brakes. Future space robotic 
systems that are exposed to long term vacuum conditions should consider the use of ceramic brake material. 

B. Software-Singularity Management 

The flight software (FSW) uses the Jacobian transformation matrix to relate joint rates to rates of the selected 
control point. When the SRMS is commanded to translate and/or rotate a defined point (tip of the SRMS or a 
selected point within the payload), the commanded joint rates are obtained using the inverse of the Jacobian. No 
solution for the commanded joint rates is available when the determinant of the Jacobian matrix is zero. There are 
three conditions that cause this for the SRMS; these three conditions are shown in Figure 11. 

These singularities cause loss of one or more controlled degrees of freedom of the arm. With the wrist yaw joint 
above the shoulder joints, ± Y translation commands cannot be accomplished (shoulder singularity). With the arm 
straight out, commands in the +X direction in the EE mode are not possible (elbow singularity). With the wrist yaw 
joint 90 degrees from the arm pitch plane, some roll commands are not possible (wrist singularity). 

These singularities are managed within the RMS software algorithms. The arm is driven through the shoulder and 
wrist singularities by the software in the automatic and manual modes. During software handling, the arm may 
deviate slightly from its commanded trajectory. The most dramatic deviation occurs if the operator commands a Y 
translation through the shoulder singularity. When the wrist yaw joint is 3 feet from being directly over the 
shoulder joint, the arm is re-oriented to drive in a circle around the singularity and then continues the Y translation. 



The operator is advised via a caution light on the D&C panel when a singularity is approached or encountered. 
The elbow singularity occurs when the SRMS elbow is reaching its maximum reach; motion is permitted until the 
elbow approaches its limits of motion. This is handled as is any joint reaching its limit. The approach to the limit 
is first announced by a caution light on the D&C panel, and then the arm motion is stopped if the operator continues 
to move further toward the limit. 
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C. Software - Consistency Check 


The SRMS, like most 
computer controlled systems, 
uses Built In Test Equipment 
(BITE) throughout the system 
to detect errors. In addition, 
there is also error detection in 
the FSW, including the 
consistency check used for 
runaway detection. Runaways 
were a particular concern for 
the SRMS because of the 
potential for damage to the 
orbiter if a payload were driven 
into the orbiter by a joint that 
had unlimited current applied to 
the motor. This never occurred 
during the history of the SRMS, 
but the potential damage 
required extra protection to 
limit the time that a runaway could exist. The consistency check provides an envelope around the commanded 
motor rate for each joint, as shown in Figure 12. 

Three components of the envelope define an offset from zero commanded motor rate, a second offset from a 
commanded rate, and a decay applied when a command is removed or changed. The actual motor rate is monitored 
and must remain within this envelope, although dynamic excursions outside the envelope are not annunciated unless 
the motor rate is outside the envelope for more than 4 consecutive computation cycles. Definition of the values for 
the envelope constants required considerable analysis at the start of the program to stop joint runaways within an 
acceptable distance of two feet, while ensuring false alarms were not generated. False alarms could be generated by 
dynamic excursions in motor rate during command changes. 

D. Test and Verification 

D.l Air Bearing Test Rig 

Since the SRMS could not support its own weight in a 1G environment, a unique test method had to be 
developed to verify the SRMS system as a whole. Individual joint drive tests could be performed with the arm 
supported in a mechanical “strong-back” ; however testing a complete arm assembly with multi -joint point of 
resolution control was not possible in this configuration. 

An air-bearing flat floor test rig was designed to allow multi-joint operation of the SRMS (see Figure 13). The 
air-bearing rig allowed forced air to be piped through special air pads mouned on the feet. This counteracted the 
effects of gravity and reduced the friction between the floor and the test rig loaded with the mechanical arm, 
allowing the arm to be driven across the floor with minimum loading. 

The arm could be mounted on the rig in pitch coupled mode or yaw coupled mode. In pitch coupled mode the 
three pitch joints could be driven, and in yaw coupled mode the two yaw joints could be driven. The wrist roll joint 
could be driven in either mode. Even though only one plane of motion could be tested at a time, it did provide 
engineers a method of verifying arm controls, tip accuracy, tip force, and multi-joint straight line controllability. 
This was the most comprehensive full up system test performed before the system was checked out on-orbit. 
Electrical Ground Support Equipment (EGSE) was used to provide power, GPC communication, and data 
monitoring. 

In addition to multi-joint drive, the air bearing test rig provided a means to monitor arm response in a 
constrained motion envirionment. With the End Effector mounted to the arm, it could be used to grapple a “payload” 
weighted down to emulate constrained motion (see Figure 13). This configuration was also used to verify the force 
capability, joint current limit response, and arm response to End Effector/grapple fixture misalignments. 
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D.2 Simulations 

Simulation of the SRMS was both a solution to the inability to fully test the SRMS on the ground and also presented 
unique challenges on its own, particularly for real-time simulation in the computers of the 70 ’s and early 80 ’s. 
When the SRMS was developed, modeling the 6-joint robotic arm was new. The coupled elements ranged from the 
orbiter (about 6216 slugs) to the light wrist links (the wrist roll joint when no payload was grappled is 3.09 slugs). 
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The bending modes of the long booms were also included, with very small effective mass. At JSC the equations 
were expressed in matrix form and generated a very ill-conditioned matrix. For non-real-time simulations these 
equations were solved in 64-bit precision. Flowever real-time computers of the day that were fast enough for the 
SRMS equations generally had only 32 bit precision (and required assembly language programming). This became a 
significant implementation challenge at JSC. 

A major JSC simulation capability throughout the Shuttle Program was the Systems Engineering Simulator 
(SES), a real-time, operator in the loop simulator that used functional FSW and a functional cockpit. As computers 
became more powerful throughout the 80’s and 90’s, the SRMS model was upgraded until it had the full capabilities 
of the best non-real-time model in 2004. 

The models developed for the SES in the 80’s and early ‘90s were also used in the Shuttle Avionics Integration 
Laboratory (SAIL) which had IBM General Purpose Computers with HAL flight software and a Flight cockpit with 
the hardware-in-the-loop MCIU for the SRMS. The remainder of the SRMS was a computer model. SAIL, which 
carried a Shuttle designation (OV-095), was used for verification of the FSW. Connecting the simulated SRMS 
model to the flight hardware was an 
additional challenge, involving 
special purpose hardware boxes as 
well as careful timing of the SRMS 
model. 

The SES combines the SRMS 
simulation with 6 DOF dynamic 
motions of two vehicles. These 
vehicles are subjected to the effects 
of orbital dynamics, aerodynamics, 
the Orbiter Digital Auto Pilot (DAP) 
thruster firings, the payload control 
system, and the RCS plume 
impingement. In the late 90 ’s, in 
response to the requirements of 
SRMS berthing studies for ISS 
assembly, various contact 
mechanism math models were also 
incorporated into the SES. The SES 
also provides the operator with out 
the window and camera views 
generated by electronic scene 
generators. Although scene 
generators are common today, the 
first electronic scene generator was developed for SES SRMS simulations. The capability was upgraded throughout 
the Shuttle program and today includes a dome simulator that provides a continuous view from overhead to the 
Orbiter payload bay. An overview of the SES aft cockpit mockup in the dome display system is shown in Figure 14. 
Modeling of the DAP as well as the SRMS in the SES allows coordinated operations of the SRMS operator and the 
DAP pilot. Throughout the Shuttle program the SES was used for engineering evaluations of changes to FSW or 
procedures that required operator inputs. In addition it was available for procedures development and crew training, 
and was used many times during flights to evaluate proposed solutions to on-orbit problems. Use of SES included 
evaluation of procedures for Detailed Test Objectives (DTOs) for the first five flights of the SRMS, track and 
capture of the first payload released and retrieved by the SRMS (SPAS-01 on STS-7), capture of rotating payloads, 
and assessing un-commanded motion. Other uses were berthing of payloads to various latching mechanisms on the 
shuttle and space station, assessment of proposed Orbiter repair techniques, and interaction between various modes 
of the Orbiter DAP and the SRMS holding the OBSS. It was also used for testing the Position Orientation Hold 
Submode (POHS) software implemented to control the un-commanded motion. 

D.3 Early Missions 

The first five flights of the SRMS included Detailed Test Objectives (DTOs) that started with the simple SRMS 
capabilities and gradually demonstrated more complex capabilities. The testing conducted on these five flights 
included: 
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Figure 14. Astronauts Joseph Acaba (at the DAP station) and 
Akihiko Hoshide (at the SRMS station) in the SES Dome Aft 
Cockpit with the OTW scene projected on the Dome surface (Source- 

Reference 2) 




STS-2: Unloaded arm tests, including single joint commanding, translational and rotational commanding of the 
tip of the SRMS, unloaded maneuvers for simulation validation, and auto mode checkout. 

STS-3: Additional unloaded arm tests including test of the backup mode, soft stop tests, and PRCS/SRMS 
interaction. First grapple of a berthed payload, maneuvers around the payload bay, and re-berth. PRCS/SRMS 
interaction with the payload on the SRMS. A capture of a second payload was not attempted because the wrist 
camera failed and payload bay cameras did not provide adequate views for re-berthing. 

STS-4: Grapple of a payload in the payload bay and maneuver around the bay to assess the payload bay 
environment, singularity management tests, PRCS/SRMS interaction with an unloaded SRMS and with the payload 
on the SRMS. 

STS-7: Release and capture of a light-weight payload (SPAS-01). Multiple releases in different EE modes were 
performed to evaluate residual rates imparted on the payload by the release. Track and capture was performed with 
the arm in manual mode and also single mode. Maneuvers were also performed to provide data for simulation 
validation. 

STS-8: Grapple of a medium weight payload (Payload Flight Test Article) and extensive maneuvering around the 
payload bay to provide data for SRMS capability checkout and simulation validation. Two grapple fixtures were 
used. One simulated the inertia of an 8K payload and the other simulated the inertia of a 16K payload. 


IV. Lessons Learned 


A. Off Nominal Operations: 

The primary mission of the SRMS was to deploy and retrieve payloads; however one of the key lessons learned 
during the life of the Shuttle program is how useful a robotic arm can be for off-nominal and contingency 
operations. As the missions and additional hardware developed, unique uses of the arm emerged. Over the life of the 
program, the SRMS allowed the mission management team to deal with a variety of unforeseen problems 
encountered on orbit. 

The reach and force 
capability of the SRMS 
provided an operational 
flexibility that was not 
available with any other 
shuttle system. A robotic 
arm provides an effective 
solution for many tasks 
that formerly either 
could not be performed 
or required EVA to 
perform. Some unique 
operations performed 
were applying force to a 
satellite antenna to lock 
it in place (see Figure 
15), supporting an EVA 
crewman performing a 
repair on Thermal 
Protection System of the 
Shuttle (see Figure 16), 

“ice busting” on STS- 
4 ID to remove a large 

icicle that formed on the shuttle’s waste nozzle; and “fly swatting” on STS-51D to engage a switch lever on a 
satellite that had been incorrectly positioned. 
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B. Position Orientation Hold Sub-mode: 

A key lesson learned during the SRMS program was the improvement in arm performance that could be 
achieved with the addition of Position Orientation Hold Sub-mode (POHS) to control un-commanded motion. 
During STS-8 while the SRMS operator was maneuvering the PFTA payload, he noted that many corrections 
were needed to control un-commanded motion. During the LDEF un-berthing on STS-41C, crew started the 
un-berthing with a pure z command, as shown in Figure 17. This provided very clear data on un-commanded 
motion. As seen in the figure, the only command is a THC z-command, but at about 11.5 inches of z 
translation, x moved about 2.5 inches (about 22% of the motion in the commanded direction), roll moved about 
1 deg, pitch moved about 'A deg (after first moving a small amount in the opposite direction), and the other axes 
moved by smaller amounts. Un-commanded POR motion is caused by a number of factors including torque 
disturbances due to dynamic coupling between the joint, friction, etc. In particular, when any joint rate crossed 
zero and friction torque changed sign, the un-commanded motion increases. This un-commanded motion was 
more significant when the commanded rate is low, and it became particularly objectionable for the deployment 
of heavy telescopes in the early 90’s. During the HST deployment on STS-31 in April 1990, crew commented 
on the heavy workload due to the un-commanded motion. Figurel8 shows the THC commands and the 
resulting translational motion, and Figure 19 shows the same data for the rotational axes. The unberthing 
command is a pure z, but that command stops and starts and many commands are also seen in all other axes. 
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STS-41C LOEF Unberth 

Orbiter Loaded Mode, Hand controller inputs and POR Position 



— PORX 
— PORY 
— PORZ 
—POR Pitch 
—POR Yaw 
—POR Roll 
— THCX 
— THCY 
— TVICZ 
— RHC Pitch 
— RHCYaw 
— RHCRdl 


Figure 17. POR commands and POR actual motion during the first part of LDEF unberthing on STS-41C 
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Figure 18. Translational Trajectory Tracking during HST Unberthing Maneuver on STS-31 

(Source- Reference 1 ) 
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To address this issue, POHS software was developed. The SRMS is a rate command system, and prior to the 
implementation of the POHS software, POR position and attitude were computed for display only. The POHS 
software uses the POR position and the commanded rate as shown in Figure 20. The figure shows two periods of 
rate command with a period of null command between them. When the SSRMS is at the initial POR position, the 
operator puts in the command Vi. The POHS software projects a reference trajectory and at each software update 
cycle (80 msce) compares 
the actual POR position to 
the projected position at 
that same time. The error 
perpendicular to the 
reference trajectory is used 
to generate POHS 
commands that will bring 
the actual position back to 
the projected position. 

When the operator 
command is nulled, the 
reference trajectory is 
projected based on the last 
command until the rates 
drop below a defined 
threshold value. At that 
point POHS goes into 
position hold and 
commands are generated 



18 

American Institute of Aeronautics and Astronautics 


to return the SRMS to that point if any un-commanded motion occurs. Figure 20 shows one axis of the POR 
computation for position; for attitude, the POHS software uses a total angle deviation from the projected attitude to 
generate the POHS commands. 

POHS software was available for the HST servicing missions after STS-64, and the reduction in workload was 
very striking during HST unberthing operations. During the missions the HST is unberthed when it is vertical in the 
payload bay and it was horizontal in the bay during the STS-3 1 unberthing, but the unbething rates were similar for 
both unberthings and commanded rate is the major driver for uncommanded motion. Figures 21 and 22 show the 
hand controller commands and actual POR motion for the STS- 103 HST unberthing. These figures show 
deviations of less than 1 inch and Vi degree. STS-3 1 deviations were larger than 25 inches and almost 10 deg. 
There were also no operator corrections during the STS- 103 unberthing with POHS. There was one roll correction 
before the unberthing started, but no attitude or position corrections during the unberthing. 


THCXCIVD 


THCYCIVD 


THCZCMD 


THO 

Rate 

Commands 
In STR 
Frame 
(counts) 



PCR X PCS DISP DL 


PCR V PCS DISP DL 



Figure 21: Translational Trajectory Tracking during HST Unberthing Maneuver on STS-103 

(Source- Reference 1) 
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RHC P QVD RHC YAW CM3 RHC R OVD 



[ Pitch Yaw Roll ] L „ Hover = [ 0 2 0] (PLID 1 ) 

Figure 22: Rotational Trajectory Tracking during HST Unberthing Maneuver on STS-103 

(Source- Reference 1) 


The POHS software was first implemented in Manual Augmented modes to address the operator workload issue. 
When Auto modes were used for Orbiter tile inspection after the Columbia accident, the operator had limited ability 
to monitor the OBSS while the boom was under the orbiter. To address this, the POHS controller was added to 
auto modes. However, an undesirable attitude oscillation was noted in position hold when the sensors on the 
OBSS scanned a specific point. This was traced to GPC precision for the very small angles seen during position 
hold, and the algorithm for calculating attitude error was changed to use a function that was less sensitive to the 
small angles. 

The value of POHS was reinforced during ISS assembly operations when the SRMS unberthed heavy modules and 
truss segments from the shuttle payload bay, often with small clearances between trunnions and the OBSS or other 
elements in the payload bay.. 

C. Command Wash-in in Auto Mode: 


Auto modes and single joint mode both 
command to a single rate, but they start the 
commands differently. In single joint mode the 
commands are ramped up over several computer 
cycles but in the auto modes the frill command is 
put in instantaneously. After the Columbia 
accident, wash-in was also proposed for auto modes 
to improve the transient response, as discussed 
below. The existing and proposed auto mode 
command profiles are shown in Figure 23. In both 
single joint and auto modes the command is washed 
out as shown in Fig 23, because abrupt nulling of 
command would cause the flexible SRMS to have 
significant overshoot and oscillations in POR and 
POR rate. There are similar overshoots and 
oscillations with a step input, and these were 

20 

American Institute of Aeronautics and Astronautics 




Figure 23: Comparison of Existing and Proposed Wash-in 
Rate Command Profiles for Auto Mode 

(Source- Reference 1) 


sufficiently objectionable in single joint mode to force wash-in of commands. For auto modes, the commands were 
initially started far enough from structure that the oscillations were not objectionable. 

When auto modes were used for OBSS inspections, the sensors had rate limits above which the images were not 
adequate for clearing tile for entry. The rate overshoots then drove reductions in the command rates to meet sensor 
requirements. Wash-in of the auto mode was proposed at this time, but it was decided that the reduction of 
command rate was an adequate solution. The effect of wash-in for a TPS inspection auto sequence is shown in 
Figure 24, which compares the rates at the start of the same auto mode with and without wash-in. The sensors had 
requirements to find 0.25 inch and 1.00 inch damage at different parts of the survey. For 0.25 in damage the 
existing software requires a POR translation rate of 0.5 meter/minute and with wash-in the rate could have been 
increased to 0.6 meter/minute. For 1 inch damage, the translation rate must be 1.4 meter/minute with the step input; 
with wash-in the translational rate limit could have been 2.7 meter/minute. 

While wash-in was not considered necessary for the SRMS, it is an improvement that should be considered 
seriously for any future space robotics. 




Time (sec) Time (sec) 

Figure 24: Effect of Wash-in on Actual Rates at Start of Auto Maneuver 

(Source- Reference 1) 


D. Value of Open Review of Simulation Models: 

At the start of the SRMS program, several different implementations of the SRMS equations of motion were 
developed by organizations including Spar, Rockwell Downey, JSC, and CS Draper Labs. At the time modeling a 
robotic space-based robotic system with the many degrees of freedom of the SRMS was a significant technical 
challenge for each organization. Early in the program, the model developed by the hardware provider Spar was 
designated as the “truth” model by the Program Office; however, the simulation was considered proprietary and the 
model and implementation were not disclosed. The truth sim, and all other sims, did not always match well with 
hardware data and sim responses did not match each other well. These differences between sim responses were a 
major topic of discussion in SRMS forums for 20 years. Even comparison to flight data did not resolve the issue 
since the errors from all sims were about equal, particularly for loads. As discussed in the section “Enhanced 
Instrumentation”, this was due to limitations of the flight data. 

Little progress was made in resolving model/implementation differences until 1999 when the SRMS Program 
office insisted on development of a “common” SRMS model and chartered the SRMS Math Model Working Group 
(MMWG) to coordinate open discussion of all model features and implementation. This resulted in co- 
development of an SRMS model that was accepted as the standard for the remainder of the Shuttle program. 

For any system used in a Program, a single model and implementation that is open for review and well grounded in 
ground testing and flight data should be provided for use throughout the Program 


E. Load Relief of Space Based Robotics: 

The SRMS was designed with relatively weak brakes at the wrist, a stronger brake at the elbow, and even stronger 
brakes at the shoulder. As a result, the wrist brakes slip under high load, and the orbiter does not see high loads at 
the longeron. The RMS for the ISS (SSRMS) made a different design choice to allow inchworm capability for the 


21 

American Institute of Aeronautics and Astronautics 


SSRMS. Either end can be the shoulder, so all joints have high strength brakes. As a result, the SSRMS can 
transmit a high load to the base, a feature that has required operational workarounds, particularly to avoid potential 
high loads if the SSRMS brakes come on as a result of a safing event while a berthing mechanism is pulling an 
element held by the SSRMS. For berthing with the element held by the SRMS, the brake torque scaling avoided 
this problem. 

A potential solution that would allow inchworm capability and also load relief would be use of dual brakes at each 
of the three end joints, with one set scaled to allow load relief, and a second brake to bring the total torque up to the 
shoulder value. Positive lockout of the second brakes at the joints that are acting as the wrist must be provided. 
The elbow joint brake torque could be scaled as the SRMS elbow brake torque was. 

Dual brakes on each of the three end joints would add mechanical complexity and weight to the robot; these need 
to be weighed against the reduction in operational complexity when load relief is important. 


F. Enhanced Instrumentation: 

The SRMS electronics provided motor rate and joint position data to the operator, and a later upgrade to the Arm 
Based Electronics added motor current data that was available for viewing on the ground. The original arm had a set 
of strain gauges, called Development Flight Instrumentation (DFI), installed however the data was of limited 
usefulness due to factors such as low resolution, poor calibration and the difficulty of retrieving the data. These 
limitations were largely due to the state of the technology at the time of development. After the Columbia accident 
one of the arms was instrumented with strain gauges and a test was performed on orbit with a crewman on the end of 
the OBSS to simulate a repair scenario. This data was useful, however the test was limited to this one scenario only. 
No data was ever collected when the arm was maneuvering large payloads, or when the arm was operating in a 
constrained motion scenario. 

As the SRMS was utilized for more varied tasks as the program progressed, including manipulating much larger 
payloads, it became clear that force and moment data would be very useful. Examples of this include using the 
OBSS on the SRMS as an EVA platform for repair of the shuttle thermal protection system, and certifying the 
SRMS to grapple the ISS and maneuver the entire Shuttle. This data would allow engineers to understand the loads 
the SRMS was exposed to which would aid in life cycle estimates. In addition, loads data would be very valuable for 
simulation. Several simulators of the SRMS were developed over the life of the program and these simulations 
played an integral part in certifying SRMS/payload operations. The major difficulty encountered was validating the 
various models that were developed for the arm. Due to the uncertainty in models developed from analysis only, 
conservative assumptions were made to ensure the uncertainty was bounded. Proper instrumentation on future 
robotic systems would aid greatly in the development of accurate models and limit the amount of analysis required. 
Additionally, significant analysis has been devoted to analyzing situations when loads can buildup due to contact 
with a berthing mechanism, grapple fixture, etc. This analysis is required because the only times that the SRMS was 
instrumented, the loads were not recorded when there was contact between the SRMS or payload and hardware 
attached to the Orbiter. The complexity of modeling contact surfaces has raised many questions that increased the 
analysis impact. Adding load instrumentation to a future robot would allow validation of contact load models with 
flight data. 

G. Force Moment Accommodation: 

Deploying and retrieving payloads primarily involves maneuvering payloads that are unconstrained. Since this 
was the mandated task of the SRMS it was designed for pure coordinated joint rate control. Flowever, for 
constrained motion when the payload can contact external structure, coordinated joint rate control is no longer 
possible. In this scenario, the direction of the applied tip force/moment will be altered and will not be as commanded 
by the operator hand controllers. This will result in motion of the arm tip in un-commanded directions. This makes 
constrained motion activities more difficult for the SRMS operator. Force moment accommodation (FMA) can 
greatly facilitate SRMS tasks involving constrained motion operations. 

The lack of FMA during the construction of the ISS underscored how useful it could be. The SRMS operational 
requirements expanded to include assembly tasks involving the mating of modules during the ISS construction. For 
these operations the limitations of velocity control became apparent. Mating operations required force application 
between surfaces that had to be correctly aligned for proper mating. Since misalignments are inherent in space 
robotic operations with limited visibility, this alignment uncertainty had to be addressed. Sophisticated visual aids 
were required for the SRMS operator to place the mating surfaces within a predefined capture envelope, and active 


22 

American Institute of Aeronautics and Astronautics 



mating latches were required to provide the force necessary to overcome the remaining misalignments within this 
envelope. Additionally, extensive preflight analysis of all the potential contact conditions during misalignments was 
necessary to ensure load limitations of the SRMS were not exceeded. 

Force and moment data displayed to the operator would provide enhanced situational awareness thus improving 
positioning accuracy. The increased positioning accuracy of the payload/mating interface would reduce the reliance 
on visual cues. The sensed force and moment data implemented in a feedback loop would control contact forces 
improving constrained motion operations. By controlling contact forces, FMA would allow the SRMS/payload to 
adapt to uncertainties in the contact environment, safe guarding against damage caused by excessive loads. This 
minimizes the need for pre-mission loads analysis. With the capability to apply constant, pre determined forces in a 
given direction, the SRMS can be used to activate berthing and latching devices. Active mating mechanisms would 
not be necessary, simplifying the mating interface design. 

Additionally, FMA can extend the capability of a robotic arm to perform complex and delicate tasks needed for 
satellite servicing. These tasks include refueling, module change outs, cleaning of surfaces, electrical connector 
mate/de-mates, and thermal blanket change outs. 

H. Expansion Capability: 

The SRMS end effector was designed with an electrical connector called the Special Purpose End Effector 
(SPEE) connector. This was envisioned as a means of providing power and data to future specially designed end 
effectors that were grappled by the standard SRMS End Effector. This connector could also electrically mate with a 
special grapple fixture called an electrical flight grapple fixture (EFGF). Payloads with this grapple fixture could 
utilize the sixteen power and data lines that ran the length of the arm in conjunction with switching panels in the 
orbiter that were configured preflight as needed. When the OBSS was developed, it utilized an EFGF to provide 
power and a data path for the cameras and lasers on the end of the boom. During the design phase it became clear 
that the existing SPEE cables could not provide the required electrical current needed by the sensors at the Shuttle 
bus voltage of 28 Volts. The work around was to use a 120 volt power source in the shuttle that was designed for use 
on the ISS. 

The limited capability of the original design of the SPEE wiring harness was a lesson learned for robotics on 
future space vehicles. Robotic systems of the future should be designed with future growth in mind. While it is 
difficult to predict future requirements, and cost limitations may restrict the amount of enhancements, it is still 
prudent to provide additional power and data paths that can be utilized for future capabilities. 


V. Conclusion 

The Shuttle Remote Manipuilator System represents one of the many great legacies of the Space Shuttle. Its 
unique capabilities were recognized as the program developed, and it evolved into much more than just a means of 
deploying and retrieving satellites. From an EVA platform, to satellite rescue and repair, to the inspection of the 
thermal protection system of the shuttle, it met the challenges of ever more complex space missions. Its success was 
a major driver in developing the Space Station Robotic Manipulator System on board the International Space Station 
today, and it will serve as the foundation for all future space robotic systems. 
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SRMS Overview 


Requirement 

Deploy and retrieve satellites from payload 
bay 

- 50 foot long anthropomorphic arm 

- Teleoperated from aft crew cabin 

Manipulator Arm 

3 joints - 6 DOF 
2 arm booms 
End Effector 
Three camera assemblies 
Thermal protection system 

Cabin Equipment 

Displays and Controls panel with rotational 
and translational hand controllers 

Manipulator Controller Interface Unit - 
interface between Shuttle GPC, D&C 
panel, and Manipulator Arm electronics 




3 


SRMS Overview 


Rotational 

Translational Handcontroller 

Handcontroller Overhead and Aft Flight Deck 

Window Views 



TV Monitors 


Display & 
Control 
Panel 


Aft Flight Deck 
RMS Work Station 


Manipulator 
Control 
Interface Unit 
(MCIU) 


GPC, CRT Monitor 
and Keypad • 


Elbow Camera 
on Pan Tilt Unit 


Manipulator 


SRMS Components 


Wrist Camera 
Sideview Camera* 
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SRMS Overview 


SRMS End Effector 

• 3-Cable mechanism snares a grapple 
fixture on payload 

• Snare mechanism is retracted to 
“rigidize” payload to End Effector 

• Grapple target used with Wrist camera 
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SRMS Overview 


SRMS Operating Modes 

• Primary Modes 

- Computer Supported Modes 

• Coordinated servo rate control - rates are pre-programmed 

• Automatic Sequences - Pre-programmed and Operator commanded 

• Manual Augmented Modes 

- Point of Resolution control via RHC and THC commands 

- POR and Co-ordinate axes based on one of five modes chosen by operator 

- Payload POR determined pre-flight 

• Single Drive 

- Single Joint Driven - other joints in position hold 

- Direct Drive Mode 

• Single joint driven with a fixed voltage - no servo rate control 

• Back-Up Drive 

- Separate electronic drive 

- Single joint driven with a fixed voltage - no servo rate control 
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SRMS History 


Satellite Deployment 

• Gamma Ray Observatory (GRO) on STS-37 

• Earth Radiation Budget Satellite (ERBS) on 
STS-41 

• Upper Atmosphere Research Satellite (UARS) 
on STS-48. 

• Satellite Deployment and Retrieval 

• SPAS-1 satellite on STS-7 -first free flyer 
capture 

• Long Duration Exposure Facility (LDEF) - 
deployed on STS-41 C, and retrieved on STS- 
32 

• Solar Maximum Mission satellite (Solar Max) 
on STS-41 C 

• Hubble Space Telescope (HST) - deployed 
on STS-31 , retrieved on 4 missions for repair 
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SRMS History 


EVA Platform 

• Developed over life of the 
program as an important use of 
SRMS for both pre-planned and 
contingency operations 

• Crewman mounted on foot 
restraint at End Effector - SRMS 
provided a platform to react forces 

• Communication from crewman to 
SRMS operator allowed quick and 
easy positioning 

• Tool stanchions and holders 
developed to aid in repairs 



STS-61 EVA Hubble Repair 
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SRMS History 


Space Station Construction 

• Primary mechanism used 
for early ISS construction 

- Nodes 

- US Lab 

- Truss segments 

- Russian Zarya Module 

• Later stages - used with the 
SSRMS to complete 
construction 

• Servo Electronics upgraded 
to improve controllability of 
heavier payloads 



P5 Handoff from SRMS to SSRMS 
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SRMS History 

Post Columbia - The Orbiter Boom Sensor System 


• OBSS developed to scan the Shuttle Thermal Protection System 

• 50 foot boom with Cameras and Laser Sensors 

• Robotically compatible with the SRMS - Electrical connector on 
End Effector provided path for power and data to Sensors 

• EVA repair of TPS - 2 Scenarios 

- Orbiter Repair Maneuver - SRMS 
grapples ISS and moves Orbiter to 
position where EVA on SSRMS can 
repair 

- Crewman on the OBSS - DTO on 
STS-121 showed feasibility of repair 
with crewman on OBSS 


OBSS Grappled by SRMS 
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Unique Challenges 



Test and Verification - Air 
Bearing Test Rig 


• 1-G environment required 
unique test method to verify 
multi-joint point of resolution 
control 

• Air Bearing test rig developed 
to allow motion in pitch plane 
or yaw plane 

• Parameters Verified: 

• Straight path Arm Control 

• Tip accuracy 

• Tip force 

• Response to misalignments 

• Current Limit testing 
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Lessons Learned 
Enhanced Instrumentation 


History 

• SRMS electronics provided motor rate and joint position data to 
operator and down listed to ground 

• Upgrade electronics added motor current data (down listed at 1 
Hertz only) 

• STS-2,3 ,4, 7 and 8 had a set of strain gauges that collected loads 
data (Development Flight Instrumentation) - this was of limited 
usefulness due to the state of the technology 

- Low resolution 

- Poor calibration 

- Difficult to retrieve data 

- Limited number of payloads - no heavy payloads 

- No constrained motion data 

• Wireless Strain Gauge Instrumentation System installed on STS- 
121 - DTO 849 tested SRMS/OBSS response to crewman applying 
loads to simulate a repair - limited data 
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Lessons Learned 
Enhanced Instrumentation 


Consequences of limited loads data 

• difficulty in validating simulation models 

• Tremendous effort spent in developing models and running 
simulations over the life of the program 

• Several models developed by different organizations that did not 
match - truth model was difficult to find 

• Life assessment was difficult 

• Due to uncertainty of models - conservative assumptions had to 
be made 
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Lessons Learned 
Enhanced Instrumentation 


• Lesson: Implement force and moment sensors in 
future space robotic systems 

• Benefits: 

• Accurate model development 

• Less analysis required - more confidence in simulations 
leads to less conservatism 

• Better assessment of Arm capability - payload handling, 
constrained motion operations, life 

• Enables Force Moment Accommodation to be implemented 
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Lessons Learned 
Force Moment Accommodation 


• SRMS designed for coordinated joint rate control only 

• Rate control not possible during constrained motion 
operations - results in un-commanded motion of arm 
tip 

• Lack of FMA noticeable during ISS construction 

• Alignment difficulties during mating of modules - 
sophisticated visual cues required 

• Pre-flight analysis of load conditions during mating was 
required to ensure structural loads were not exceeded 
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Lessons Learned 
Force Moment Accommodation 


Lesson: Implement FMA in future robotic systems 
Benefits: 

• Better positioning accuracy during mating operations - less 
reliance on visual cues 

• Adaption to external contact forces - lower loading 
conditions and reduces need for pre-mission analysis 

• Ability to activate berthing and latching devices by applying 
pre-determined forces in commanded direction 

• Complex satellite servicing tasks can be performed; 
refueling, module change outs, connector mate/de-mates 



Unique Challenges: 
Software Singularity Management 


There are 3 SRMS control 
singularities due to zeroes in the joint 
rate to tip rate Jacobian 

- Shoulder singularity: wrist yaw joint 
directly over shoulder joint no +/- y 
translation control 

- Elbow singularity: all pitch joints are 
colinear: no +x control 

- Wrist singuarity: wrist yaw joint at +/- 
90°: limited roll control 

Software control may cause 
unexpected motion 

- Shoulder singularity: 3 feet from Wrist 
yaw directly over shoulder yaw, wrist 
yaw is reconfigured to opposite side of 
singularity zone 

- Elbow singularity: No change in 
motion 

- Yaw singularity: roll motion continues 
at a reduced rate 
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Unique Challenges: 

Software Consistency Check 

• Runaway of an SRMS joint due to a fault that applies unlimited current to 
the motor would potentially drive a payload through orbiter structure and 
required special protection 

- No runaway ever occurred during the 30 year Shuttle program 

• The software consistency check monitored actual motor rate for each joint 
against an envelope around the motor rate command 

- If the actual motor rate for any joint was outside its envelope for more than 4 
consecutive GPC cycles (to allow for motor dynamics), the SRMS brakes are 
applied 
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Unique Challenges: 

Simulation 

• Simulation provided solution to inability to fully test SRMS in 1-g but 
also provided challenges with computers of 70’s and 80’s 

- Real-time simulation computers did not have both speed and high precision 
required by SRMS model; approximations eliminated in 2004 

- Testing flight software running in Orbiter computers required special purpose 
hardware boxes to connect Orbiter computer with simulated SRMS 

• JSC’s Systems Engineering 
Simulator (SES) combined SRMS 
simulation with 6 DOF dynamic 
motion of two vehicles 

- Vehicles subjected to orbital 
mechanics, aerodynamics, orbiter 
jet thruster firings, payload control 
system, RCS plume impingement, 
berthing contact forces 

- Functionally equivalent orbiter aft 
cockpit mockup provides displays 
and controls for SRMS and for 
orbiter Digital Autopilot (DAP) 

- Scene generators provide out the 
window and CCTV views 
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Unique Challenges: 

Simulation 

Uses of SES 

• SES provided capability to test SRMS operations that require 
operator in the loop and also integrated SRMS and Orbiter DAP 
operations (such as approach to free flying payload and capture 
with SRMS) 

• SES was used throughout the Shuttle program for engineering 
evaluation and also used by Mission Operations personnel for 
procedures development and crew training 

• Uses of SES included assessment of: 

- Procedures for operations on early flights that tested SRMS 

- Track and capture of first payload released and recaptured by SRMS and of 
rotating payloads 

- Uncommanded motion and software used to control it 

- Berthing payloads to various latching mechanisms on ISS and shuttle 

- Proposed Orbiter repair techniques 

- Interaction of DAP firings in different modes and SRMS holding various payloads 
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Lessons Learned: 

Position Orientation Hold Submode 

The Problem 

• The SRMS was initially purely a rate command system 

• Early operators noted uncommanded motion that required significant 
correction commands 

• During LDEF unberthing on STS-41C, crew did not correct uncommanded 
motion during 1 1 inches of unberthing (z) motion 

- Most significant uncommanded motion was 2 inches x and 1 deg roll 


STS-41C LDEF Unberth 

Orbiter Loaded Mode, Hand controller inputs and POR Position 



Time (Seconds) 


60 


45 
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POR Z 

POR Pitch 
POR Yaw 
POR Roll 
THC X 
THC Y 
— THC Z 

RHC Pitch 
RHC Yaw 
RHC Roll 


• In the early 90’s, when large telescopes were unberthed the uncommanded 
motion became very objectionable 
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Lessons Learned: 

Position Orientation Hold Submode 

The Solution 

• POHS software was developed that added position correction commands to 
the rate commands, based on the actual motion of the commanded point 

- Initial position and command used to generate projected trajectory 

- At each computer cycle, actual position compared to projected position and error 
perpendicular to reference trajectory used to generate POHS commands to 
bring actual position back to projected position 



• The following charts show the difference between the translation/rotation 
commands and motion for Hubble Space Telescope unberthings on STS- 

31 (no POHS) and STS-103 (POHS active) 
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Lessons Learned: 

Position Orientation Hold Submode 


THCXCMO 
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SRMS translation commands and command point motion for STS-31 (left) and STS-103 (right) 
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Lessons Learned: 

Position Orientation Hold Submode 


RHCPCIVD 


RHCYAWCIVD 


RHCRQVD 


RHCYAWCIVD 


RHC 

Rate 

Command: 
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Frame 
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POR 

Pitch 

Angle 
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Roll 
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POR Yaw 
Angle 
in ORAS 
(in) 





[ Pitch Yaw Roll ] Low Hover = [ 0 0 0] (PLID 2) 


HST unberth trajectory is from Berthed Position 
to Hover Position: 

[ Pitch Yaw Roll ] Berthed = [ 0 2 0] (PLID 1 ) 
[ Pitch Yaw Roll ] Low Hover = [ 0 2 0] (PLID 1 ) 


SRMS rotation commands and command point motion for STS-31 (left) and STS-103 (right) 
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Lessons Learned: 

Position Orientation Hold Submode 


Uses of POHS 

• POHS was initially developed for manual modes to alleviate operator 
workload controlling uncommanded motion, as shown in STS-31 and 
STS-103 unberthings 

- STS-31 had multiple rotation and translation commands during unberthing 

- STS-103 had one roll command before the unberthing command; no 
commands in other axes during unberthing 

- Uncommanded motion on STS-31 (no POHS) was over 25 inches and almost 
10 deg; for STS-103 (with POHS) it was less than 1 inch and about 14 deg. 

• After Columbia accident when OBSS was used in auto mode to inspect 
Orbiter tile and crew had limited visibility of OBSS under orbiter, POHS 
was added to auto modes 

• POHS was very valuable during unberthing of large ISS modules and 
truss segments for ISS assembly 

- Many cases of close clearance with OBSS or other elements in the Orbiter 
Payload Bay during unberthing 
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Lessons Learned: 
Command Wash-in in Auto Mode 


• SRMS Auto mode commands a 
constant rate from start point to 
near end point 

- Command washes out to prevent 
overshoot of end point and rate 
oscillations 

• After Columbia accident wash-in 
was also proposed for start 

- Rate oscillations at start 
forced reduction in 
commanded rate so 
oscillations did not exceed 
sensor limits for damage 
detection 

- NASA elected to reduce 
commanded rate instead 

• Bottom figure compares rate 
oscillations with and without 
wash-in for 2.4 and 0.6 meters 
per minute 






Time (sec) Time (sec) 
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Lessons Learned: 

Value of Open Review of Simulation Models 

History 

• When the SRMS program started, modeling a 6 DOF space based 
robotic system was a technical challenge for all organizations 

• Multiple organizations developed models independently 

• Model developed by hardware provider defined as “truth” model but 
considered proprietary so model and implementation not disclosed 

• Responses of models had differences 

- With each other 

- With truth sim 

• All sims, including truth sim, had about equal errors with: 

- Ground test data 

- Flight data 

• Accepted model only defined after SRMS Program Office required 
development of “common” model and chartered MMWG to facilitate 
open discussion of model and implementation details (completed 
2004 ) 
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Lessons Learned: 

Value of Open Review of Simulation Models 

Consequences of limited insight into proprietary model 

• 20 years of discussion of model/response differences at different 
forums without resolution 

• Operations designed conservatively to cover model uncertainties 

Lesson Learned 

• Models used by a program should be open for review and well 
grounded with ground test data and flight data 

Benefits 

• Avoids duplication except when necessary (necessary if modeling a 
system at the limit of standard practice) 

• Less time trying to understand differences 

• Accurate model developed early in program 
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Lessons Learned: 

Load Relief in Space Based Robotics 

History 

SRMS has scaled brakes: weaker at wrist, stronger at elbow, strongest at 
shoulder 

- Wrist brakes slip under high load and orbiter does not see high loads at longeron 

SSRMS design choice was to use equal strength brakes at all joints 

- Provides inchworm capability 

- Requires operational workaround to avoid potential high loads if brakes come on 
while berthing mechanism is pulling element held by SSRMS 

Proposed design to allow both inchworm capability and load relief would 
use two brakes at end joint and reduced strength brakes at elbow 

- First brake scaled to provide load relief when that end is used at tip 

- Second brake adds torque to make total torque adequate for shoulder 

- Requires positive lockout of second brake at tip joints 

Dual brakes add mechanical complexity and weight 

- Need to weigh against gain in load relief, if important 



